HL7 CDA
The Clinical Document Architecture is an HL7 standard for exchanging clinical documents: a discharge summary, a referral letter, a laboratory report. It is XML, derived from the HL7 v3 Reference Information Model, and it has been in production use since 2005.
New national programmes generally choose FHIR. CDA remains relevant because an enormous installed base exists, because some jurisdictions still mandate it, and because the document concept it embodies solves a problem FHIR's resource model does not solve by itself.
- Tier 1 · HL7 International · https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
What a document is, and why it matters
A CDA document has six defining characteristics, and they are the reason the standard exists:
- Persistence — it continues to exist unchanged over time
- Stewardship — an organisation is responsible for it
- Potential for authentication — it is legally attestable
- Context — it carries its own context (patient, author, encounter, time)
- Wholeness — attestation applies to the whole, not to fragments
- Human readability — a human must be able to read it without special software
Point 6 is enforced structurally: every CDA document contains a narrative block that a browser can render with a stylesheet, alongside the coded entries. A receiving system that cannot process the codes can still show the clinician the document.
This is a genuinely different guarantee from a FHIR query result. A query returns what the server holds now; a document is a signed, immutable statement of what a named clinician asserted at a point in time. In legal and medico-legal contexts, that difference is the whole point.
Structure
┌─────────────────────────────────────────────┐
│ CDA Header │
│ patient, author, custodian, encounter, │
│ document type (LOINC), effective time, │
│ authenticator, confidentiality │
├─────────────────────────────────────────────┤
│ Body │
│ ┌───────────────────────────────────────┐ │
│ │ Section — e.g. "Allergies" (LOINC) │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ Narrative text (human readable) │ │ │
│ │ └─────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ Entries (coded, machine │ │ │
│ │ │ readable — SNOMED CT, LOINC) │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └───────────────────────────────────────┘ │
│ … further sections … │
└─────────────────────────────────────────────┘
The header is always structured. The body ranges from unstructured (a PDF wrapped in a header) to fully coded — the three "levels" implementers refer to:
| Level | Body | Interoperability achieved |
|---|---|---|
| 1 | Unstructured or narrative only | A human can read it |
| 2 | Sections coded with LOINC | A system can find the allergies section |
| 3 | Entries coded with terminology | A system can process individual allergies |
Level 3 is where semantic value lives, and where the implementation cost is. Many production deployments run at Level 2 with selected Level 3 sections, which is a reasonable engineering compromise.
C-CDA and other templates
CDA on its own is a framework; real exchange uses templates, the CDA equivalent of a FHIR implementation guide.
- C-CDA (Consolidated CDA) — the US template set: Continuity of Care Document, Discharge Summary, Referral Note, and others. https://www.hl7.org/implement/standards/product_brief.cfm?product_id=492
- epSOS / European Patient Summary — the lineage behind the International Patient Summary, which originated in CDA before being expressed in FHIR.
- Numerous national template sets.
CDA and FHIR together
They are not mutually exclusive, and the most common real architecture uses both.
| CDA | FHIR | |
|---|---|---|
| Unit of exchange | A document | A resource, or a Bundle |
| Format | XML only | JSON, XML, RDF |
| Access | Push, or document-sharing infrastructure (IHE XDS/MHD) | REST API, plus documents, messages and bulk |
| Granularity | Whole document, attested | Individual resource, queryable |
| Human readability | Required, built in | Optional text element |
| Learning curve | Steep — RIM-derived, verbose | Shallow — ordinary REST and JSON |
| Best at | Legally attested clinical statements, referral and discharge | Querying, apps, incremental exchange, analytics |
FHIR supports documents too: a Bundle of type document with a Composition
as the first entry gives you the same document semantics in FHIR's model. If you
need attested documents in a new FHIR-based architecture, use that rather than
retaining CDA.
Conversion. CDA↔FHIR conversion is mechanically possible and semantically lossy in both directions. The header maps cleanly; coded entries map reasonably; narrative and attestation semantics do not survive round-tripping. Treat conversion as a migration step with human review, not an ongoing integration strategy.
When document exchange is still the right pattern
- Cross-organisational referral and discharge, where the receiving clinician needs a coherent, attested snapshot rather than the ability to query
- Legal or regulatory attestation requirements
- Low-trust or low-bandwidth exchange, where a signed package can be transported by any means, including offline
- Existing document-sharing infrastructure (IHE XDS registries and repositories) already in production
See health information exchange for how document exchange compares with API and event-based patterns.
References
- HL7 CDA R2 product brief — https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
- C-CDA — https://www.hl7.org/implement/standards/product_brief.cfm?product_id=492
- FHIR documents — https://hl7.org/fhir/documents.html
- IHE document sharing (XDS, MHD) — https://www.ihe.net/